Extensible Markup Language (XML) is a markup language that is designed to describe data. XML documents use a self-describing syntax. For example, using XML, one might describe a note from one person to another. The note might consist of multiple elements, such as a “to” element, a “from” element, a “head” element, and a “body” element.
An XML document is “well formed” if the XML document has the correct XML syntax. A well-formed XML document is “valid” relative to a schema if the XML document conforms to the rules expressed by the schema. Thus, an XML document may be well formed, and yet invalid relative to a particular schema.
A schema defines rules to which an XML document must conform in order to be considered valid relative to that schema. A schema may be, for example, an XML Schema or a Document Type Definition (DTD). A schema's rules might require, for example, that an XML document must have a “to” element, a “from” element, a “head” element, and a “body” element in order for the XML document to be valid relative to the schema.
To determine whether an XML document is valid relative to a schema, a program called a “validator” may process both the XML document and the schema. The validator determines whether the structure and content of the XML document conform to the rules expressed in the schema. If the validator determines that the XML document fails to conform to a rule expressed in the schema, then the validator outputs an error. The error may indicate the rule to which the XML document failed to conform. The validator may output a separate error for each detected failure to conform to the schema. The process of determining whether the XML document conforms to the schema's rules is called “validation.”
XML documents may describe data in a specific contextual domain. For example, an XML document might express distinct portions of a note, or connections between network elements in a network topology. However, due to the generic nature of validators, the errors output by a validator typically convey little or no information regarding the meaning of those errors within the XML document's specific contextual domain. For example, an error might generally indicate that a particular element required by a schema was missing from an XML document, but that error would not convey specific information indicating that a particular network element was disconnected from other network elements in the network topology expressed by the XML document.
Theoretically, context translation programs might be designed to facilitate the translation of non-context-specific errors into context-specific messages. However, different validators might output different errors in response to detecting the same rule violation within an XML document. Furthermore, the errors output by a validator might change if a new version of the validator is released. If the translation mechanisms were hard-coded into a context translation program, then the context translation program's source code would need to be modified and recompiled before the context translation program could handle error messages that the context translation program was not designed to handle as of the context translation program's last compilation time.
Often, though, end users of such context translation programs would not possess the knowledge or means needed to modify and recompile source code.